A thread is an independent flow of control within a process. Threads models are the different implementations of multithreading techniques that are provided by a computer operating system. Multithreading is a technique that allows performing of multiple tasks in a single program (process) concurrently.
FIG. 1 is a block diagram illustrating various threads models. The components shown in FIG. 1 operate within or are implemented in a computer (not shown). In an M×1 threads model 105, the user threads (UT) 110a, 110b, 110c are scheduled by a user scheduler 115 to execute within the process context. As known to those skilled in the art, a user thread (UT) is a thread that is visible to the application (i.e., visible in the user space application) and is managed by a threads library. The kernel is not aware of the user threads and schedules of the underlying process. Since the threads library is responsible for management and scheduling of the user threads, the kernel scheduler 120 does not manage and schedule the user threads 110a–110c. The kernel scheduler 120 schedules this process on the central processing unit (CPU 125). As known to those skilled in the art, the operating system resides in the area known as the kernel space. The kernel is represented by the dashed lines 161 in FIG. 1 and contains the kernel scheduler 120.
A bound thread is defined as a user thread that is directly bound to a kernel thread. In contrast, unbound threads are user threads that are multiplexed over one or more kernel threads. Unbound threads are maintained in the user space library and execute in the context of the underlying kernel thread (KT). The kernel threads (KT) are kernel schedulable entities that are visible to the operating system kernel. The kernel threads are generally created from the userspace threads library by calling a particular system call.
In a 1×1 threads model 130, the user threads (UT) 135a, 135b, and 135c are bound to the underlying kernel threads (KT) 140a, 140b, and 140c. The bound threads are scheduled directly by the kernel scheduler 120. There is no userspace scheduler for scheduling the user threads (UT) 135a, 135b, and 135c. Note that a userspace is an area where the user programs reside. The underlying kernel threads 140a, 140b, and 140c are scheduled by the kernel scheduler 120 on CPUs 125a and 125b. In the 1×1 threads model, when a user thread blocks in the kernel, other user threads can continue to run on their corresponding kernel threads.
In an M×N threads model 150, the user threads (UT) either can be multiplexed on top of a kernel thread (M×1 threads model) as in the case of the user threads 155a, 155b, and 155c, or bound to the underlying kernel threads (1×1 threads model) as in the case of the user thread 155d. The multiplexed user threads are scheduled by the M×M user scheduler 115a and the bound user threads (e.g., UT 155d), and their underlying kernel threads 160a, 160b, and 160c are scheduled by the kernel scheduler 120. Related details about the M×M threads model and scheduler activation (SA) blocking/unblocking are described further in, for example, Ulrich Drepper, “Design of the New GNU Thread Library”, (Apr. 13, 2002), which is hereby fully incorporated herein by reference.
The M×N threads model is the most flexible and the most complex of the three thread models described above. Excessive I/O (input/output) bound applications do not work well for the M×N threads model and hurt the performance of the unbound threads. The reason for these problems is that the M×N models need to have blocking/unblocking upcall mechanism (or similar mechanism) to make sure that when one unbound user thread blocks in the kernel, other unbound user threads can make progress (i.e., run). As known to those skilled in the art, an upcall mechanism is a notification mechanism that is used by the kernel to inform the threads library of some event happening in the kernel, such as for example, the kernel needs to sleep for some resource. However, this mechanism has significant overhead if all the unbound user threads keep performing blocking and unblocking, as this operation involves creating a new kernel thread from the kernel when an unbound user thread blocks and the return of the original kernel thread after the thread unblocks. This operation is expensive when performed very often and significantly affects the application performance. This negative effect on performance was seen when running the industry standard VolanoMark benchmark with the M×N threads. Because of the complexity and high overhead with the M×N threads model, various latest products have discontinued the support for the M×N threads model. For example, the M×N threads model is not supported by the Solaris 9 product from Sun Microsystems, Inc., and is not implemented in Linux due to the overhead associated with the M×N model. In contrast, the bound user threads do not have the above-mentioned overhead, as bound user threads have 1-to-1 mapping with the kernel thread.
Thus, the current approaches and/or technologies are limited to particular capabilities and/or suffer from various constraints.